The fast development of telecommunications has made it possible for operators to offer users a large number of different services. A network architecture that provides advanced services is called an intelligent network. The common abbreviation for intelligent network is IN.
The functional architecture of an intelligent network is shown in FIG. 1 where the functional entities of the network are shown as ovals. This architecture is described briefly below, because the invention will be described later by referring to the intelligent network environment.
The access of the end user (subscriber) to the network is handled by the CCAF (Call Control Agent Function). The access to the IN services is implemented by making additions to existing digital exchanges. This is done by using the basic call state model BCSM which describes the existing functionality used to process a call between two users. The BCSM is a high level state automaton description of the call control functions CCF required for establishing and maintaining a connection route between users. Functionality is added to this state model by using the service switching function SSF (cf. the partial overlap of the entities CCF and SSF in FIG. 1) so that it is possible to decide when it is necessary to call the services of the intelligent network (the IN services). After these IN services have been called, the service control function SCF that contains the service logic for the intelligent network handles the service-related processing (of the call attempt). The service switching function SSF thereby connects the call control function CCF to the service control function SCF and allows the service control function SCF to control the call control function CCF. For example, SCF can request that the SSF/CCF performs specific call or connection functions, for example, charging or routing operations. The SCF can also send requests to the service data function SDF which handles the access to the services-related data and network data of the intelligent network. The SCF can thereby, for example, request the SDF to retrieve specific service-related data or update this data.
The functions described above are further complemented by the specialized resources function SRF which provides the special functions required for implementing some of the services provided by the intelligent network. Examples of these services are protocol conversions, speech recognition and voice mail. The SCF can, for example, request the SSF/CCF functions to first establish a connection between the end users and SRF and then it can request the SRF to give voice messages to the end users.
Other functional entities of the intelligent network are various functions that relate to control, such as the SCEF (Service Creation Environment Function), SMF (Service Management Function), and SMAF (Service Management Access Function). The SMF includes, among other things, service control, the SMAF provides the connection to the SMF, and the SCEF makes it possible to specify, develop, test and feed IN services via the SMF to the SCF. Because these functions only relate to the operation of the network operator, they are not shown in FIG. 1.
The role of the functional entities described in FIG. 1 as related to the IN services is described briefly below. The CCAF receives the service request given by the calling party. The service request usually consists of lifting the receiver and/or a series of digits dialled by the calling party. The CCAF further transmits the service request to the CCF/SSF for processing. The call control function CCF does not have the service data but it has been programmed to recognize the need of a service request. The CCF interrupts the call setup for a moment and notifies the service switching function SSF about the state of the call. The task of the SSF is, using predefined criteria, to interpret the service request and thus determine whether the request is a service request related to the IN services. If this is the case, the SSF composes a standardized IN service request and sends the request to the SCF along with information about the state of the service request. The SCF receives the request and decodes it. After that it cooperates with the SSF/CCF, SRF, and SDF to provide the requested service to the end user.
The physical level architecture of the intelligent network describes how the functional entities described above are located in the physical entities of the network. The physical architecture of the intelligent network is illustrated in FIG. 2 where the physical entities are described as rectangles or circles and functional entities as ovals. The signalling connections are described by dashed lines and the actual transport which is, for example, speech, by continuous lines. The optional functional entities are marked by dashed line. The signalling network shown in the Figure is a network according to SS7 (Signalling System Number 7 is a well-known signalling system described in the CCITT (nowadays ITU-T) blue book Specifications of Signalling System No. 7, Melbourne 1988).
The subscriber equipment SE which can include, for example, a phone, computer, or a telefax, are connected either directly to a service switching point SSP or to a network access point NAP.
The service switching point SSP provides the user with access to the network and handles all necessary selection functions. The SSP can also detect any IN service requests. Functionally, the SSP includes the call control and service selection functions.
The network access point NAP is a traditional telephone exchange that includes the call control function CCF, for example, a DX 220 exchange which can differentiate calls that require IN services from traditional calls and route the calls that require IN services to the appropriate SSP.
The service control point SCP includes the service programs that are used to produce the IN services.
The service data point SDP is a database containing customer and network data which is used by the service programs of the SCP to produce tailored services. The SCP can use SDP services directly or via the signalling network.
The intelligent peripheral IP provides special services, such as announcements and voice and multiple choice recognition.
The service switching and control point SSCP consists of an SCP and SSP located in the same node (in other words, if the SSP node shown in the drawing contains both an SCF and an SSF entity, the node in question is an SSCP).
The tasks of a service management point SMP include the management of the database (SDP), network monitoring and testing, and collecting network data. It can connect to all other physical entities.
The service creation environment point SCEP is used for specifying, developing and testing the IN services, and for entering the services in SMP.
The service adjunct AD is functionally equivalent to the service control point SCP, but the AD is directly connected to SSP with a fast data connection (for example, with an ISDN 30B+D connection) instead of via the common channel signalling network SS7.
The service node SN can control the IN services and perform data transfers with users. It communicates directly with one or more SSPs.
The service management access point SMAP is a physical entity which provides certain users with a connection to SMP.
The above is a brief description of the intelligent network as a background to the description of the method according to the invention. Interested readers can get a more detailed description of the intelligent network in, for example, ITU-T specifications Q.121X or in the AIN specifications of Bellcore.
As described above, SSF sends standardized IN service requests to SCF in certain phases of the call setup. Because the service control point SCP (or the service adjunct AD) is typically a centralized node of the network which serves several exchanges, it is also important that different load measurements are continuously performed in the database of such a centralized service point. For example, the SCP (or AD) can be divided for such measurements into functional parts as shown in FIG. 3. The lowest layer is formed by the so-called platform layer 31 which contains the hardware and the basic operating system (for example, Unix). On top of the platform layer is located the application-specific layer 32 which can be divided into the following three parts: service database (SDB) 32a, service logic programs block (SLP) 32b, and measurement programs block (MP) 32c. Service logic programs are the programs which are triggered by the service requests arriving in the node and provide the actual IN service. These programs thereby perform processing tasks on a call by call basis. The measurement program block, on the other hand, is the entity that handles the processing related to the SCP load. The measurement program block does not therefore perform its tasks on a call by call basis, but it performs its operations, for example, by recording interval or in certain situations, for example, in overload situations.
The service database typically contains data tables (DT) in which each subscriber has a row Ri (i=1,2, . . . n) of its own. The subscriber identifier OI is included at the beginning of each row as the key. Essential for the invention are the data tables that relate to the aforementioned measurements. One such measurement table corresponds to a group of measurement objects that is called a (measurement) module. The measurement tables of several measurement modules can be put in the same data table, or the measurement table of each measurement module can form a separate data table. A measurement table thereby refers to a module-specific data set that can be a part of a data table in the system or an entire data table. The measurement module will also be referred to as a measurement group.
In the system each subscriber has a dedicated set of counters which are incremented as a result of different events related to the subscriber; for example, the call counter is incremented for each call. The values of the counters are collected by recording interval.
FIG. 3 illustrates the application environment of the method by still using the service control point SCP of an intelligent network as an example. Generally speaking it can be said that the method can be applied to any service database system which randomly receives service requests which are answered by the system. Such a system is described below on a general level without limiting the description to an SCP node of an intelligent network.
So that incoming service requests can be answered, the processor with access to the database must perform service-specific processing. The (measurement) objects related to the service requests are represented by individual rows of the data tables of the database system, which rows are handled by the processor. The system records the number of requests and certain events during recording intervals of specific length.
The objects can be classified into object classes so that all objects in a class are of the same type (for example, subscribers), when the situation is examined from the perspective of the events that are being recorded. Objects of the same type can be formed into a measurement group and more than one measurement group can be defined within each object class. Within each measurement group, each object has related counters which are used to record the events. The counter values can vary from one object to another, but a specific event is interpreted identically by each object; for example, certain events can mean a number translation request for each subscriber (i.e. for each object).
The functionality related to measurement includes the following recording functions regardless of the environment in which the service database system is situated.
As each request is received, a dedicated instance of the service logic procedure is created, the data row of the desired object is retrieved from the data table, and the requested service logic processing is performed. In a measurement group, each individual data row has a related counter group which is used to record the occurrence of different events. During service logic processing the counter values are incremented according to the occurrence of the desired events which are to be recorded.
Furthermore, it would be preferable to put the same processor to handle the service processing, the functions related to recording the events (incrementing the counters), and the recording of counter values for several different measurement groups. The recording of counter values refers to the operation where the counter values are retrieved at regular intervals so that they can be written in the memory (log file) or sent to an outside system for processing. In practice, the use of one processor may be the only option. The reason for this is that often the service requests include stringent response time requirements in which case the database must be implemented in RAM memory (not on disk). It is not even possible in all commercial computer systems to have more than one processor accessing a single RAM memory. RAM memory shared by several processors is also difficult to implement because overlapping memory operations must be prevented.
This kind of a service database system contains a large number of measurement groups,each of which can be active (measurement is performed for the group in question) or passive (measurement is not performed for the group in question). Each group can also have certain activation and deactivation times at which the management system activates/deactivates the group. In this kind of an environment the problem is how the system should function during the activation/deactivation of a single measurement group so that the measurement group can be activated at any point in a simple and speedy manner and also deactivated without interfering with the current measurement. The problem is especially how to implement the zeroing of this kind of a very large counter group during the activation of a single measurement group or the activation of the entire measurement (system startup) which is the prerequisite for starting the measurement.
In conventional systems the zeroing has been implemented so that the database management system gives the zeroing command for all counters during the module activation command, at which point the counters of all objects have been zeroed. This is not, however, a good solution especially when the number of objects is very large, as it easily leads to overload of the processor which performs the zeroing and in that way to delays which delay the starting of the measurement.